IV. REMARKS 



1 . The title and specification are amended. Claims 1, 10, 11, 
13, 30, 38, and 39 are amended. Claims 40-41 are new. 

2. Claims 13 and 38 have been amended to address the 35 U.S.C. 
§101 re j ections . 

3. The claims are amended to address the 35 U.S.C. §112, second 
paragraph rejections . 

4. Applicant has submitted all known version of the SyncML Sync 
Protocol, it is aware of . Version 1.0 is dated December 7 , 2000 
and Version 1.0.1 is dated June 15, 2001 . Copies are again 
attached hereto. 

5. Applicant respectfully submits that there is no evidence to 
support a publication date earlier than the release date of 
version 1.0 of the SyncML Synch Protocol . There is no indication 
of the publication or release of the intermediate versions 
reflected in the Revision History section on page 2 of both 
version 1.0 and 1.0.1. It is submitted that there is no evidence 
to support an effective publication date as of 1999, as has been 
suggested. Applicant has attempted to obtain-copies of the 
earlier reference version, but has not had any success , and 
submits they do not exist publicly. 

Applicant encloses a copy of a document entitled "Materials from 
Af f iliates-SyncML. " This document provides a listing of 

available documents related to the SyncML protocol specification, 
and does not make anything publicly available earlier than 
version 1.0. 
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Applicant also encloses a document entitled "XML-Managing Data 
Exchange/SyncML. " The document states that "SyncML started as an 
initiative in mid 2000." With respect to document releases, the 
document states that the "consortium released version 1.0 in 
December 2000." This is consistent with the Revision History 
that states that Revision 1.0, dated December 7, 2000, was the 
"candidate version or the final release." 

Furthermore, even if there were any valid publication of the 
SyncML specification that could properly be a prior art 
reference, the reference does not teach each feature claimed by 
Applicant and does not anticipate Applicant's invention under 35. 
U.S.C. §102. 

Claim 1 recites determining "coding instructions" by which at 
least one of the required identifiers can be coded into a bit 
sequence requiring substantially fewer bits than the identifiers 
ASCII presentation. The identifiers are the identifier of the 
synchronization server, the version identifier and the identifier 
of the requested synchronization server. These features are not 
disclosed or suggested by SyncML. 

In SyncML version 1.0.1, chapter 4 describes synchronization 
initialization (Figure 6; Packages #1 and #2). Chapter 8 
describes the Server Alerted Sync preceding synchronization 
initialization (Figure 10, Package #0). i.e. the possibility of a 
synchronization server to indicate to a synchronization client 
need for starting a synchronization session, in order for the 
synchronization client to initiate synchronization 

initialization . The One_Way sync from client described in 
Chapter 6, only discloses the general package flow of a specific 
sync type and initialization is merely mentioned as precondition 
(Figure 8). Chapter 4.1 discloses initialization requirement for 
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a synchronization client, i.e. what the client shall include in a 
initialization message (Package #1) to a synchronization server. 
Chapter 4.2 specifies requirements of synchronization server for 
initialization (Package #2), i.e. after receiving the 
initialization message from the client, but has nothing to do 
with transferring a request from the server to the client 
indicating need for starting a session (which would be done by 
the Package #0) . Chapter 8 regards contents of a request from 
the synchronization server to a synchronization client for 
indicating need for starting a session. 

However, there is no disclosure in SyncML related to coding 
instructions, by which at least one of the identifiers (an 
identifier of the synchronization server, a version identifier, 
and an identifier of the requested synchronization session) can 
be coded into a bit sequence requiring substantially fewer bits 
than its ASCII presentation, in the synchronization server, and 
decoding instructions, by means of which the original identifier 
is obtained from the bit sequence, in the client device. 

There is also no disclosure of applying such coding instructions 
for arranging presentation of at least one of identifiers in a 
bit sequence defined according to the coding instructions in a 
message for request indicating need for staring a session to a 
client device (which would be the Package #0) as claimed by 
Applicant. Further, there is no disclosure of storing and 
applying decoding instructions in a client device utilized for 
converting information to be used to form an initialization 
message as is claimed by Applicant. 

Significantly, SyncML does not disclose or suggest forming an 
initialization message such that at least part of the information 
in the initialization message is defined from the received bit 
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sequence by means of the decoding instructions as is claimed. 
While the Examiner refers to section 4.3.1 of SyncML, this 
section only describes the need to resend the sync initialization 
package again later. There is no disclosure here, or elsewhere 
in SyncML, of "forming an initialization message on the basis of 
information included in the received message" where at least part 
of the information is defined from the received bit sequence by 
means of the decoding instructions as claimed. Thus, at least 
this feature cannot be anticipated. 

One advantage of the recited claims is the reduced message size 
and the availability of a single short message by a server to 
trigger session initiation. This is not seen in the cited 
reference . 

Thus, each feature of claim 1 is not disclosed or suggested by 
SyncML. Thus, the claim cannot be anticipated. Claims 10, 11, 
13, 30, 38 and 39 recite similar features, and are equally not 
anticipated. Claims 2-9, 15-22 and 31-37 should be allowable 
at least by reason of their respective dependencies. 

It is respectfully submitted that all of the claims now present 
in the application are clearly novel and patentable over the 
prior art of record, and are in proper form for allowance. 
Accordingly, favorable reconsideration and allowance is 
respectfully requested. Should any unresolved issues remain, the 
Examiner is invited to call Applicants' attorney at the telephone 
number indicated below. 

Checks in the amount of $120 and $400 are enclosed for a one- 
month extension of time and two additional independent claims 
(40-41) . The Commissioner is hereby authorized to charge payment 
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for any fees associated with this communication or credit any 
over payment to Deposit Account No. 16-1350. 



Reg.Hlo. 44,004 M 

Perman & Green, LLP 
425 Post Road 
Fairfield, CT 06824 
(203) 259-1800 Ext. 134 
Customer No. : 2512 



I hereby certify that this correspondence is being deposited with 
the United States Postal Service on the date indicated below as 
first class mail in an envelope addressed to MAIL STOP AMENDMENT, 
Commissioner of Patents, P.O. Box 1450, Alexandria, VA 22313- 
1450. 





CERTIFICATE OF MAILING 




Signature : 
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